1. Field of the Invention
Apparatuses and methods consistent with the present invention relate to executing different Java methods.
2. Description of the Related Art
Object-oriented programming is a method of developing a computer program and is based on an object and data rather than an action and logic. Traditionally, programs were typically considered as performing logic operations, that is, receiving an input, processing the input and outputting a processing result. Programming was considered as a method of writing logic rather than a method of defining data. Conversely, object-oriented programming is an approach having a view such that an object is more important than logic in a program. Examples of an object include a human being (described by a name, an address, etc.), a building, a retailer store (whose properties can be described and handled) for selling goods, and a very small element such as a button or a scroll bar on a desktop of a computer.
The first stage of the object-oriented programming is an operation which is generally referred to as data modeling for identifying all objects to be handled and the relation between the objects. After all objects are identified, they are generalized into object classes, and types of data that the object classes contain and all logical sequences that can handle the object classes are defined.
A logical sequence is called a method, and an actual instance of a class is called a single “object” or a single “class activator” in some cases. An object or an activator is executed on a computer. A method defines a computer instruction and the properties of a class object define the related data.
Java is programming language which is designed to be used particularly in a distributed environment of the Internet. Java code appears similar to C++ language but Java is easier to use than C++ and enhances complete object orientation of programming. Java can be used to produce an application program which is executed in a single computer or in a distributed client/server environment on a network. In addition, Java can also be used to produce a small application program module or applet used as a part of a web page. Applets enable users to interact through a web page.
Meanwhile, a Java program can be executed using an interpreter scheme or a compiler scheme. In the interpreter scheme, program codes are read one by one and executed. In the compiler scheme, a code written in machine language is executed. Since instructions are executed one by one, the interpreter scheme does not burden a system but is very slow in comparison. The compiler scheme is faster than the interpreter scheme but requires a large amount of memory capacity since the entire program is loaded into memory.
FIG. 1 illustrates a method by which a Java class code is operated by an interpreter and a compiler. A Java source code 1 is an original program code that is written in accordance with the format of Java language using an editor. The Java source code 1 is human readable but is not machine readable. The Java source code 1 is compiled using a bytecode compiler 2 into machine language, i.e., a bytecode 3, which is executed in a Java virtual machine 500. The Java virtual machine 500 serves as an emulator executing the bytecode 3. The Java virtual machine 500 independently executes the bytecode 3 in hardware. The same bytecode 3 can be executed in different types of hardware because the Java virtual machine 500 emulates the hardware.
The Java virtual machine 500 executes the bytecode 3 in specific hardware or a specific operating system (OS). For execution, an interpreter 510 that interprets instructions one by one using the interpreter scheme and a compiler 520 that compiles the bytecode 3 to machine language and directly executes the bytecode 3, which is in machine language form, using the compiling method are present.
Meanwhile, the Java virtual machine 500 executes a bytecode differently according to an execution frequency of a method. For example, when a method has not been frequently called, a bytecode in the interpreter scheme (hereinafter, referred to as an “interpret code”) is executed. When a method has been frequently called, a compiled machine code (hereinafter, referred to as a “native code”) is executed. Accordingly, when a call between different Java methods occurs, management of a stack which stores execution states such as a parameter, a return address, and a local variable, is needed in order to take into account the characteristics of the Java virtual machine 500. In particular, a method that has been executed in the interpreter scheme should be able to be executed in the compiler scheme at any time in order to increase execution performance. Conversely, to reduce the use of memory, a method that has been executed in the compiler scheme should be able to be executed in the interpreter scheme. Thus, it is important for a Java virtual machine 500 to be able to provide interoperability between different methods. Many methods of managing a stack when a call occurs between different methods have been proposed.
FIG. 2 illustrates a conventional technology of managing a stack with respect to a call occurring between different methods. The conventional technology relates to performing a call between methods using a mixed execution stack, as disclosed by U.S. Pat. No. 6,009,517. A frame for a method which is executed in an interpret code (i.e., a Java frame) and a frame for a method which is executed in a native code (i.e., a C++ frame) are stored in a single execution stack. In the control flow between the frames, information is exchanged through an entry frame that is present between the frames. However, a frame of the interpret code and a frame of native code are constructed in different formats and it is very complicated to convert the frame of native code into the frame of the interpret code when changing the compiled method into the interpreter method is needed.
FIG. 3 illustrates a conventional technology of translating a bytecode into a compiled code. An interpreter 22 and a compiler 23 are included in a Java virtual machine 24 and execute a class file 21, as disclosed by U.S. Pat. No. 6,292,935. When a native method which is generated using the compiler 23 calls a method of an interpret code, the interpret code is unconditionally compiled by the compiler 23 so that a single stack structure can be used. As a result, interoperability can be achieved. However, reduction of a memory occupation rate, which is an advantage of the interpreter 22, is not accomplished because even codes that can be executed by the interpreter 22 are compiled.
FIG. 4 illustrates a conventional technology in which a bytecode and a compiled code refer to different stacks. A stack 31 for a method executed using an interpreter and a stack 32 for a native method are independently configured and managed, as disclosed by U.S. Pat. No. 6,604,167. Here, since different formats of frames exist in different stacks, respectively, it is difficult to use this technology when an execution scheme for the method is changed.
According to the above-described conventional technologies, in order to accomplish interoperability between methods, a single stack is configured for different formats of frames, different formats of frames are respectively stored in different stacks, or an interpret code is translated into a compiled code. However, these technologies do not increase real-time interoperability between an interpret code and a compiled code. When the different stack frames are used, rapid code conversion and execution cannot be guaranteed. In particular, when a digital apparatus uses embedded Java, it is necessary to use a single common format of a stack to accomplish interoperability between an interpret code and a native code and translation between codes appropriate to memory capacity.